第1章 ソフトウェアコンストラクションへようこそ
第1回 2020/05/06(水) 19:00
進行担当: akht.icon
はじめに
「ソフトウェアエンジニアリングのベストプラクティスと、平均的なプラクティスとの差は非常に大きい。おそらく他のエンジニアリング分野におけるそれよりも大きいだろう。良いプラクティスを普及させるツールが重要である」
Fred Brooks
コンストラクション（construction）：ソフトウェアの開発フェーズの中で、ほぼ詳細設計からテストまでの部分を指す。その中心は、コーディングとデバッグである。
hr.icon
第1章はこんな内容だった
本書ではコンストラクションを扱う
コンストラクションとは何か
なぜコンストラクションが重要か
全体的に「うんうん」って話が書いてある
第1章
ソフトウェアコンストラクションへようこそ
=> 一般的には、おおむね、何かを作ることの実践的な部分
補足イメージ
建築業者（construction workers）
工作用紙（construction paper）
1.1 ソフトウェアコンストラクションとは
コンピュータソフトウェアの開発は複雑なプロセスになる場合がある。
「場合がある」？複雑にならないケースのほうがレアでは？
関わる人数・経過時間が増大するほど複雑度が上がるような気がする
ソフトウェア開発を構成するアクティビティ
課題定義
要求開発
コンストラクション計画
ソフトウェアアーキテクチャ（または概略設計）
詳細設計
コーディングとデバッグ
単体テスト
統合テスト（または結合テスト）
統合
システムテスト
保守
↑これらのうち、課題定義以外はソフトウェア開発のコンストラクションに含まれる
しかし中心となるのはコーディングとデバッグ
本書もそこに重点を置く
プログラミングと同じ意味
優れた創造力と判断力が必要なもの ≠ 機械的なものではない
1.2 なぜソフトウェアコンストラクションは重要か
多くの人にとってこの２つの改善が重要であることに異論はないはず
ソフトウェアの品質を高めること
開発者の生産性を高めること
そこで、問い
ソフトウェア開発の改善が重要であるとして、なぜコンストラクションがそれらの改善の重要な鍵を握るのか？
答えはこんなところ
コンストラクションはソフトウェア開発の大部分を占める
プロジェクト全体の30%〜80%の時間を占める
つまりこの部分がプロジェクトの成功を大きく左右する
コンストラクションはソフトウェア開発の中心的なアクティビティである
仕様書だとかアーキテクチャだとかはコンストラクションの前に作られる
システムテストはコンストラクションが正しく行われたことを確認するためのもの
あくまで中心はコンストラクション
コンストラクションに専念することで、個々のプログラマの生産性は驚くほど向上する
コンストラクション（プログラミング）における個々のプログラマの生産性には10倍〜20倍の開きがあるらしい
Sackman, Erikson and Grant 1968
（確かによく聞く話だし、実感としてもわかる）
プログラミング自体もだけど、デバッグの際のあたりの付け方とかも生産性の違いがある
コンストラクションの成果物であるソースコードは、多くの場合、ソフトウェアを正確に書き表した唯一のドキュメントである
仕様書や設計書は最新じゃないことが多い
（そもそも存在しないことも...）
ソースコードだけが常に最新
なのでソースコードの品質を高めようとするのは当然
コンストラクションは必ず実行される唯一のアクティビティである
要件定義・設計・包括的なテストは必ずしも実施されない
しかしコンストラクションだけは必ず実施される
（コンストラクション = プログラミングなのでそれはそう）
よって、コンストラクションを改善することは、ソフトウェア開発作業を改善させることにつながる
（そのほかの工程をどれだけ省こうとも）
1.3 本書の読み方
本書は最初から順番に読んでも、トピックごとに読んでもいい
最初から順番に読んでいきたい場合
第2章に進む
プログラミングに関する特定のヒントを探している場合
第6章に進む
どっちで進めたらいいかわからない場合
第3章に進む
1.4 まとめ
コンストラクションの方法をどれだけ理解しているかが、どれだけ優秀なプログラマであるかを決める。これが本書のテーマである